Skip to main content

Session protocol

After connecting to the websocket, a session needs to be created, and data interaction with the affective cloud computing platform is performed in the session. The operations for the session are as follows:

ServiceOperationDescription
sessioncreateAuthenticate and create session
restoreRestore session
closeEnd the session

Session Create & Authentication​

Create and authenticate a session.

caution

All services requesting affective cloud computing must first undergo session authentication.

Request of session authentication and creation​

{
    "services": "session",
    "op": "create",
    "kwargs": {
        "app_key": app_key, # APP Key generated by the cloud background
        "user_id": userid, # md5 hash value of the unique user id associated with the session
        "timestamp": timestamp, # real time timestamp
        "sign": sign, # See sign steps for details
        "upload_cycle": upload_cycle # upload cycle multiple (see table)
    }
}

Upload cycle(upload_cycle)​

In the interface of V2 and above, the client is supported to upload data according to the upload cycle of different multiples. Users can set the upload cycle by setting the upload_cycle parameter according to their needs. Setting the upload cycle can effectively reduce resource consumption and save interface usage costs. Under different upload cycle multiples, the number of data packet frames uploaded by the client each time is also different, and the time interval between uploading data packets and receiving calculation result packets from the affective cloud server will also increase as the multiple increases. Refer to specific parameters Party content.

tip
  • The upload cycle multiple can be any integer between 3 ~ 100 (a multiple of 3 or less is required, please contact customer service)
  • Cycle description of different modules of Affective Cloud supporting hardware：
  • EEG
    • The theoretical packet sending interval of Affective Cloud supporting hardware is 0.012 seconds for each packet (each packet is 20 bytes long)
    • The upload cycle is doubled, and the client needs to receive 50 packets from the hardware; each time the number of multiples increases, the number of packets increases by 50 packets
    • The upload cycle is doubled, the theoretical time interval from the first packet received by the hardware to the 50th packet by the client is 0.6 seconds (0.012 * 50), and the time interval is extended by 0.6 seconds every time the cycle is doubled
    • For example: to set a 3 times upload period, the client needs to receive 50 3 = 150 packets from the hardware (theoretical time interval is 0.6 3 = 1.8 seconds) before uploading data to the server; the server processing is complete, return valid data.
  • ECG
    • The theoretical packet sending interval of Affective Cloud supporting hardware is 0.2 seconds for each packet (each packet is 1 byte long)
    • The upload cycle is doubled, and the client needs to receive 3 packets from the hardware; each time the number of multiples increases, the number of packets increases by 3 packets
    • The upload cycle is doubled, and the theoretical time interval from the first packet to the third packet received by the client from the hardware is 0.6 seconds (0.2 * 3). Each time the cycle is doubled, the time interval is extended by 0.6 seconds
    • For example: to set a 3 times upload cycle, the client needs to receive 3 3 = 9 packets from the hardware (theoretical time interval is 0.6 3 = 1.8 seconds) before uploading data to the server; the server has finished processing.

Reference table for upload cycle multiples

MultipleCumulative number of EEG packetsCumulative number of HR packetsTheoretical cycle time (seconds)Description
0302EEG: 0.36; HR: 0.40 times Only old users who use the v1 version of the interface are allowed to use
15030.6
315091.8The default multiple; if you want to use a smaller multiple, please contact customer service
10500306

sign step​

  • Get the app_secret from the background.
  • Sort the string to be signed according to the parameter name; (first compare the first letter of all parameter names and arrange them in abcd order, if you encounter the same first letter, look at the second letter, and so on)
  • Concatenate the sorted parameters into a string;
  • Then do md5 on the spliced ​​string;
  • The values ​​after md5 are all converted to uppercase.

For example: Sign the following parameters:

app_key = "c821db84-6fbd-11e4-a9e3-c86000d36d7c",
app_secret = "b1a071f0d3f119de465a6d8c9a8c0e7f",
timestamp = 1566971668, # real-time timestamp
user_id = "098f6bcd4621d373cade4e832627b4f6"

sign_str = "app_key={}&app_secret={}&timestamp={}&user_id={}".format(
    app_key, app_secret, timestamp, user_id
) # Sort the string to be signed according to the parameter name (first compare the first letter of all parameter names and arrange them in abcd order. If the same first letter is encountered, look at the second letter, and so on)

sign = hashlib.md5(sign_str).hexdigest().upper() # sign is the signature value (all uppercase required)

user_id​

user_id is the value of the unique user id in the developer app after md5 hashing. user_id can be used to locate the attribution of the session user, and can be used for subsequent data association query and error tracking.

tip
  • The unique user id in the App can be mobile phone number, email address, user id, account name, etc., but the uniqueness must be guaranteed.
  • What we save is only the value after md5, and we don't know the original id of the user in the app.
  • The user_id uploaded by the user must be an md5 value, and the timestamp and user_id uploaded through the verification interface must be exactly the same as those of the signature.

Response of session authentication and creation​

{
    "code": 0,
    "request": {
        "services": "session",
        "op": "start"
    },
    "data": {
        "session_id": session_id # Session ID, each Start connection will generate a unique ID, which can be used for session recovery
    }
}

Session Restore​

Restore the session. The session was interrupted due to poor network conditions and you can choose to restore it.

tip
  • The session retention time is 10 minutes. The session can be restored based on the session_id within 10 minutes, and the session will be destroyed if it exceeds 10 minutes.
  • The retention time of the test application is 2 minutes.

Response of session restore​

{
    "services": "session",
    "op": "restore",
    "kwargs": {
        "app_key": app_key, # APP Key generated by the cloud background
        "session_id": session_id, # Session ID, generated by Session Start
        "user_id": userid, # md5 hash value of the unique user id associated with the session
        "timestamp": timestamp, # real time timestamp
        "sign": sign, # see sign steps for details
        "upload_cycle": upload_cycle # upload cycle multiple (see table)
    }
}

Response of session restore​

{
    "code": 0,
    "request": {
        "services": "session",
        "op": "restore"
    }
}

Session Close​

Close the session.

[!WARNING] Be sure to call session close after the session ends, otherwise the server will still keep the session and incur charges.

Request of session close​

{
    "services": "session",
    "op": "close"
}

Response of session close​

{
    "code": 0,
    "request": {
        "services": "session",
        "op": "close"
    }
}